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The  Priority  Ceiling  Protocol:  A  Method  for  Minimizing 
the  Blocking  of  High-Priority  Ada  Tasks 

Abstract.  The  priority  ceiling  protocol  is  a  new  technique  that  addresses  the  priority 
inversion  problem,  i.e.,  the  possibility  that  a  high-priority  task  can  be  delayed  by  a 
low-priroity  task.  Under  the  priority  ceiling  protocol,  a  high  priority  task  can  be  blocked 
at  most  once  by  a  lower  proirity  task.  This  paper  defines  how  to  apply  the  protocol  to 
Ada.  In  particuiar,  restrictions  on  the  use  of  task  priorities  in  Ada  are  defined  as  well  as 
restrictions  on  the  use  of  Ada  tasking  constructs.  An  extensive  example  illustrating  the 
behavior  guaranteed  by  the  protocol  is  given.") 

This  paper  was  presented  at  the  2nd  International  Workshop  on  Real-Time  Ada  Issues 
,n  May  1988.  ^ 

I.  Introduction 

At  the  First  International  Workshop  on  Real-Time  Ada  Issues,  it  was  reported  that  a  high-priority 
Ada  task  can  be  delayed  indefinitely  by  lower  priority  tasks  under  certain  condittons  [1].^  The 
delay  of  a  high-priority  task  by  a  lower  priority  task  is  called  priority  inversior).  Priority  inversion 
occurs  because  of  task  synchronization  requirements  and,  therefore,  cannot  be  completely 
eliminated;  but  it  can  be  minimized.  Two  recently  defined  protocols  for  scheduling  real-time  proc¬ 
esses  provide  solutions  to  the  priority  inversion  problem  [4].  Both  protocols  assume  the  use  of 
binary  semaphores  to  synchronize  access  to  shared  resources.  In  this  paper,  we  extend  these 
protocols  to  Ada. 

The  basic  priority  inheritance  protocol,  as  defined  in  [4],  has  the  foltowing  important  property; 

If  m  distinct  semaphores  are  used  by  n  lower  priority  processes,  a  process  can  be 
blocked  for  at  most  the  duration  of  min(m,  n)  critical  sections  [4]. 

Hence,  the  basic  priority  inheritance  protocol  places  an  upper  bound  on  the  blocking  delay  that  a 
process  can  encounter.  The  priority  celling  protocol  [4]  Improves  the  basic  priority  inheritance 
protocol  by  minimizing  the  blocking  time  of  a  process  to  at  most  the  duration  of  a  single 
(outermost)  critical  section  of  a  lower  priority  process.  It  also  prevents  nontrivial  forms  of  dead¬ 
lock. 

The  basic  priority  inheritance  and  ceiling  protocols  can  be  applied  to  Ada  1)  if  Ada  tasks  are 
written  following  certain  mles  and  2)  if  the  mles  governing  the  scheduling  of  tasks  are  changed 
slightly.  In  essence,  the  idea  is  to  represent  each  semaphore  as  a  server  task.  Each  critical 
region  is  represented  as  an  entry  of  the  task.  For  example,  consider  two  processes,  and  J2, 
that  access  a  single  semaphore.  S; 

J, -{....P{S) . V(S) . P(S) . V(S)....} 

J2 P(S) . V(S)....} 

The  corresponding  Ada  task  structure  is  shown  in  Figure  1 . 

'These  conditions  are  not  unique  to  Ada.  They  can  arise  in  any  system  in  which  the  need  to  access  shared  resources 
causes  a  low-priority  task  to  block  the  execution  of  a  Ngher  priority  task. 
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task  body  T1  Is 
begin 

Server.EI ; 

Server.E2; 

endT; 

task  body  T2  Is 
begin 

Server.E3; 

end  T2; 


--  corresponds  to  J, 

-  corresponds  to  first  critical  region  of 

-  corresponds  to  second  critical  region  of  J■^ 

-  corresponds  to  J2 

-  corresponds  to  critical  region  of  J2 


task  body  Senrer  is  --  contains  critical  regions  guarded  by  semaphore  S 

begin 

loop 


select 

accept  El  do ...  end  E1 ; 

-  J^s  first  critical  region 

or 

accept  E2  do ...  end  E2; 

~  J^‘s  second  critical  region 

or 

accept  E3  do ...  end  E3; 

--  J2S critical  region 

or 

terminate; 

end  select; 

end  loop; 
end  Server; 

Figure  1 :  Critical  Regions  Mapped  as  Ada  Tasks 


To  apply  the  priority  ceiling  protocol  in  Ada,  a  programmer  must  obey  the  following  restrictions  on 
the  use  of  Ada  tasking  features: 

1.  All  accept  statements  in  a  task  must  be  contained  in  a  single  select  statement  that 
is  the  only  statement  in  the  body  of  an  endless  loop.  There  must  be  no  guards  on 
the  select  alternatives  and  no  nested  accept  statements.  (Such  a  task  structure 
models  the  notion  of  aitical  regions  guarded  by  a  semaphore,  thus  allowing  us  to 
apply  the  previously  developed  theory  to  a  system  of  Ada  tasks.  A  task  that  con¬ 
tains  such  accept  statements  is  called  a  server  task.  A  dient  task  is  a  non-senrer 
task  that  contains  at  least  one  entry  call.)^ 

2.  There  must  be  no  conditional  or  timed  entry  calls.  (These  forms  of  call  have  no 
simple  analogues  in  the  binary  semaphore  version  of  the  theory;  they  are  excluded 
to  simplify  our  application  of  the  theory  to  Ada.) 

3.  Each  task  must  be  assigned  a  priority.  (Hence,  the  execution  of  one  task  can  be 
preempted  by  the  execution  of  a  higher  priority  task.) 


task  that  contains  no  accept  statements  or  entry  calls  is  a  non-senmr  task  but  not  a  dient  task.  Therefore,  the  set  of 
non-server  tasks  is  not  the  same  as  the  set  of  dient  tasks 
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4.  A  server  task  must  have  a  priority  lower  than  that  of  any  of  its  dient  tasks  (This 
restridion  ensures  that  entry  calls  are  executed  with  the  correct  priority.  For  ex¬ 
ample,  in  the  simplest  case,  a  rendezvous  is  executed  with  the  priority  of  the  calling 
task.  This  corresponds  to  executing  a  critical  region  with  the  priority  of  the  process 
that  contains  it.) 

Further  theoretical  work  may  allow  the  priority  ceiling  protocol  to  be  extended  to  a  wider  variety  of 
Ada  tasking  strudures,  but  the  purpose  of  this  paper  is  to  indicate  the  advantages  of  the  protocol 
when  it  is  applied  directly  to  Ada.  Given  these  restrictions,  using  the  priority  ceiling  protocol  on  a 
single  processor  guarantees  the  following  properties  [4]: 

1 .  The  queue  for  a  particular  entry  can  have  at  most  one  calling  task.  (Hence,  priority 
queues  are  not  needed.) 

2.  If  a  task  is  queued  for  one  alternative  of  a  select  statement,  no  tasks  are  queued  for 
any  other  alternatives.  (Hence,  at  most  one  entry  call  is  queued  for  a  given  senrer 
task  and  there  is  no  need  to  specify  that  in  a  seledive  wait,  the  highest  priority 
queued  task  is  seleded  for  execution;  there  is  at  most  one  waiting  task.) 

3.  Execution  of  a  high-priority  non-server  task  can  be  delayed  by  at  most  one  lower 
priority  dient  task  for  at  most  the  duration  of  the  longest  entry  call  made  by  that 
task.  (This  is  a  bounded  form  of  priority  inversion.) 

4.  Deadlock  cannot  occur  as  long  as  a  task  does  not  call  itself.^ 

5.  Blocked  calls  to  the  same  senrer  are  serviced  in  order  of  priority. 

The  following  sedion  defines  the  priority  ceiling  protocol  for  Ada. 


2.  The  Priority  Ceiling  Protocol  for  Ada 

A  server  task  is  a  task  whose  accept  statements  are  all  contained  in  a  single  seled  statement 
that  is  the  only  statement  in  the  body  of  an  endless  loop.  Senrer  tasks  are  the  only  form  of  task 
allowed  to  contain  an  accept  statement  under  the  current  version  of  the  priority  ceiling  protocol.  A 
client  task  is  a  non-senrer  task  that  contains  at  least  one  entry  call.  A  server  task  is  said  to  be 
executing  on  behalf  or  client  task  T  if  the  server  has  been  called®  either  by  T  or  by  a  server  task 
that  is  executing  on  behalf  of  T.  The  priority  ceiling  of  a  server  task  is  defined  as  the  highest 
priority  of  its  client  tasks,  i.e.,  the  highest  priority  of  tasks  that  can  call  the  server  diredly  or 
indiredly.  For  example,  suppose  client  task  T,  calls  server  1 .  In  addition,  dient  task  T2  calls 
server  2,  and  server  2  calls  server  1  during  its  rendezvous  with  task  T2.  The  priority  ceiling  of 
server  1  is  the  maximum  priority  of  tasks  T,  and  Tj. 

The  priority  ceiling  protocol  uses  the  following  definitions; 


non-Miver  task  that  makes  no  entry  calls  can  have  a  priority  lower  than  the  priority  of  a  senrer  task.  A  client  task 
can  have  a  priority  lower  than  a  server  task  if  it  never  calls  that  server,  directly  or  indirectly. 

^Qiven  the  mapping  from  critical  regions  to  Ada  tasks,  having  a  task  cal  itself  would  be  equivalent  to  trying  to  lock  a 
semaphore  while  inside  a  critical  region  guarded  by  that  semaphore.  The  priority  oeiling  protocol  prevents  deadlock 
caused  by  mutual  wailing;  e.g.,  under  this  protocol,  it  cannot  be  the  case  that  server  task  S1  is  attempting  to  call  server 
task  S2  while  S2  is  attempting  to  call  SI . 

*The  calling  task  is  either  queued  on  an  entry  or  the  server  is  in  rendezvous  with  the  caller. 
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1.  Let  T  be  a  client  task  attempting  to  call  a  sen/er.  The  attempted  call  is  blocked 
unless  Ts  priority  is  greater  than  the  priority  ceiling  of  each  server  task  that  is 
executing  on  behalf  of  some  task  other  than  T.^ 

2.  A  server  task  S  is  said  to  block  the  execution  of  non-server  task  T  if  S  is  executing 
on  behalf  of  some  other  client  task  U,  T's  priority  is  greater  than  U’s, 

a.  T  is  attempting  to  call  a  server  (not  necessarily  S),  and  S  has  a  priority 
ceiling  greater  than  or  equal  to  T's  priority,  or 

b.  S  is  called  by  a  server  that  blocks  the  execution  of  T,  or 

c.  S  is  blocking  the  execution  of  some  task  whose  priority  is  higher  than  Ts 
priority. 

Definition  1  is  used  later  when  defining  how  blocked  calls  are  processed.  Definition  2  is  used 
later  to  define  the  execution  priority  of  a  server  task.  Definition  2b  defines  a  form  of  blocking  that 
can  occur  when  a  task  is  not  making  or  executing  an  entry  call. 

Given  the  restricted  usage  of  Ada  constructs  and  the  definitions  of  blocking,  the  priority  ceiling 
protocol  is  defined  as  follows; 

1 .  When  an  attempted  entry  call  is  blocked,  the  call  is  not  made  and  the  calling  task's 
execution  is  suspended.^  (This  ensures  that  at  most  one  task  is  queued  for  a 
server  task.) 

2.  A  server  executes  at  its  assigned  priority  except  when  it  is  executing  on  behalf  of  a 
client  task.  In  this  case,  it  executes  at  the  priority  of  its  client  unless  oile  3,  below, 
requires  execution  at  a  higher  priority.  (This  mie  means  a  sen/er  task  can  execute 
at  higher  than  its  assigned  priority  even  if  it  is  not  in  a  rendezvous.  Although  the 
priority  of  a  server  task  is  increased  by  this  rule,  the  server  is  not  said  to  inherit  its 
client's  priority;  instead,  it  is  considered  to  be  executing  as  part  of  its  client  and 
therefore  executes  at  its  client's  priority.) 

3.  If  a  senrer  blocks  the  execution  of  one  or  rrxjre  tasks,  the  server  executes  with  the 
highest  priority  of  the  tasks  it  blocks^  until  the  server  has  completed  execution  of  an 
accept  statement,  at  which  point  its  execution  priority  becomes  the  higher  of  either 
Ks  assigned  priority  or  its  priority  as  determined  by  these  rules.  (Since  it  will  usually 
be  the  case  that  a  higher  priority  task  is  ready  to  run  when  the  rendezvous  is 
completed,  the  server  task  is  usually  preempted  after  completing  a  rendezvous. 

The  server  is  said  to  inherit  the  priority  of  the  highest  priority  blocked  task.  This  rule 
allows  the  execution  of  a  lower  priority  client  task  to  delay  the  execution  cf  a 
medium-priority  task  when  the  lower  priority  task  has  called  a  server  and  the  server 
is  blocking  the  execution  of  a  high-priority  task.  The  medium-priority  task  pays  this 
price  to  avoid  blocking  the  high-priority  task.  This  is  a  form  of  priority  inversion.) 

Note  that  the  priority  of  a  server  task  changes  depending  on  which  tasks  it  is  serving  or  blocking, 
and  that  a  server  can  block  tasks  that  are  not  requesting  service;  i.e.,  a  calling  task  can  be 


*lf  a  server  task  attempts  to  call  artolher  server,  the  priority  ceiling  protocol  guarantees  that  this  call  will  never  be 
blocked. 

^Note  that  a  call  is  blocked  if  the  server  task  is  executirtg  a  rerxfezvous  or  H  arwther  task  is  queued  on  an  entry,  since 
the  server's  priority  ceiling  will  necessarily  be  greater  than  or  equal  to  the  caller's  priority  14).  Thus  the  above  rule  includes 
the  usual  condition  under  which  a  calling  task  is  blockad.  However,  the  difference  here  is  that  the  calling  task  is  blocked 
betom  the  call  is  actually  made  and  placed  in  an  entry  queue. 

'The  priority  of  the  blocked  tasks  will  ahways  be  higher  than  the  priority  of  the  server's  client  task. 
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blocked  even  though  the  called  server  is  not  executing  any  call.^  Moreover,  when  a  rendezvous 
is  completed,  the  set  of  blocked  tasks  can  change:  in  particular,  (at  most)  one  task  can  be  un¬ 
blocked. 

The  basic  priority  inheritance  protocol  is  like  the  priority  ceiling  protocol  except  for  the  definition  of 
blocking;  an  attempted  call  is  blocked  (Definition  1)  and  a  server  blocks  a  calling  task  (Definition 
2a)  only  if  the  called  task  is  executing  on  behalf  of  some  task,  i.e.,  blocking  does  not  take  into 
account  priority  ceilings  or  whether  other  senders  are  executing. 

In  [4],  the  following  theorem  was  proved;^^ 

Theorem  1:  A  set  of  n  periodic  non-server  tasks  using  the  priority  ceiling  protocol  can 
be  scheduled  by  the  rate  monotonic  algorithm  [2]  H  the  following  conditions  are  satis¬ 
fied; 

C,  C,  C  B 

Vi.  ISfSn.  ^  +  + 

'1  ^2  ‘i  U 

where, 

•  is  the  execution  time  of  non-server  task  tj  (the  execution  time  includes  the 
time  required  to  execute  an  entry  call  when  there  is  no  preemption  or  blocking). 

•  7j  is  the  period  of  non-server  task  tj. 

•  B,  is  the  worst-case  blocking  time  of  non-sen/er  task  Xj,  i.e.,  the  longest  entry 
call  that  can  be  made  by  a  lower  priority  client  task  that  calls  a  server  whose 
priority  ceiling  is  greater  than  or  equal  to  Xj’s  priority.^  ’ 

Task  Xj  has  a  higher  priority  than  task  Xj  if  /< 

For  example,  suppose  that  we  have  three  non-server  tasks.  For  highest  priority  task  x^ ,  we  first 
check  if  equation  C,/T,  +  B,/T,  s  1  holds.  Next,  we  check  if  equation  C^/T,  +  Cg/Tg  +  B2/T2  < 
2(2f'2  _  1)  hoijjs  iQc  jask  X2.  Finally,  we  check  If  equation  C,/T,  +  C2/T2  +  C3/T3  +  ByTg  <  3(2^'^ 
-  1)  holds  for  task  Xg.  If  all  three  equations  hold,  then  the  tasks  will  meet  all  their  deadlines:  i.e., 
each  task  will  complete  its  work  before  the  start  of  tts  next  period. 

The  first  /  terms  in  the  theorem’s  inequality  constitute  the  effect  of  preemptions  from  all  higher 


*For  example,  suppoce  server  SI  has  been  called  by  a  task  at  priority  1  and  then  a  task  at  priority  2  attempts  to  call 
server  S2.  If  Si's  priority  ceiling  is  equal  to  or  higher  than  2,  task  2's  call  will  be  blocked  even  though  S2  is  able  to  accept 
it.  This  seemingly  unrtecessaty  blocking  is  in  fact  the  key  to  the  success  of  the  priority  ceiling  protocol  The  protocol 
ensures  that  when  a  task  preempts  a  server  and  attempts  tc  .i^l  another  server,  the  new  server  will  never  block  a  higher 
priority  task  if  the  call  is  successful. 

’*The  theorem  has  been  reworded  to  apply  to  Ada. 

'’Note  that  task  t,  can  have  a  non-zero  blocking  time  (i.e.,  can  be  delayed  by  the  execution  of  a  lower  priority  task) 
even  if  it  makes  no  entry  calls,  since  blocking  time  is  determined  by  entry  calis  made  by  lower  priority  tasks.  This  is  an 
example  of  push-through  Uockirtg  (see  the  Appendix). 

'^Note  that  lor  purposes  of  applying  this  theorem,  task  has  the  highest  priority,  although  in  Ada  a  task  with  prionty  n 
would  have  the  highest  priority.  In  the  scheduling  literature,  toe  notational  convention  is  that  task  t,‘s  priority  is  higher  than 
tj  if  r  <  /.  In  addition,  use  of  the  rate  monotonic  algorithm  means  that  T,  <  T.  (i.e..  higher  priority  tasks  have  shorter 
periods) 
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priority  tasks  and  tj's  own  execution  time,  while  Bj  in  the  last  term  represents  the  worst-case 
delay  caused  by  the  execution  of  lower  priority  tasks.  Blocking  delays  occur  because  of  task 
synchronization  requirements.  The  theorem  specifies  a  sufficient  (worst-case)  condition  that 
characterizes  the  rate-monotonic  schedulability  of  a  given  periodic  task  set.  Tighter  bounds  were 
also  given  in  [4]. 


3.  Summary 

Both  the  basic  priority  inheritance  protocol  and  the  priority  ceiling  protocol  correct  the  unbounded 
priority  inversion  problem  caused  by  existing  Ada  rules.  However,  the  priority  ceiling  protocol 
minimizes  the  blocking  of  high-priority  tasks  better  than  the  basic  priority  inheritance  protocol. 
Under  the  priority  ceiling  protocol,  a  task  can  be  blocked  by  lower  priority  tasks  at  most  once.  In 
addition,  this  protocol  prevents  mutual  deadlocks  as  long  as  each  task,  when  executing  alone, 
does  not  deadlock  with  itself.  Finally,  the  implementation  of  this  protocol  may  well  be  simpler 
than  the  current  niles  since  at  most  one  task  can  be  queued  per  server  task  and  only  one 
priority-ordered  queue  need  be  kept— the  queue  of  tasks  that  are  ready  to  run  or  blocked.  It  also 
seems  likely  that  a  useful  set  of  real-time  applications  can  be  programmed  using  the  limited  form 
of  sen/er  tasks  currently  allowed  by  the  protocol  (see  the  companion  paper  [3]).  Further  work  is 
underway  to  extend  the  protocol  and  verify  its  utility. 
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Appendix 

A  given  task’s  execution  can  be  delayed  in  two  ways:  either  it  is  preempted  by  the  execution  of  a 
higher  priority  non-server  task  (or  the  execution  of  a  server  on  behalf  of  such  a  task),  or  it  is 
blocked  by  a  server  executing  on  behalf  of  a  lower  priority  task.  The  priority  ceiling  protocol  limits 
the  amount  of  blocking  of  a  task  to  at  most  one  sen/er  call  made  by  a  lower  priority  task,  whereas 
the  amount  of  blocking  for  the  basic  priority  inheritance  protocol  can  be  more.  Blocking  can  occur 
in  three  ways: 

•  Direct  blocking:  the  called  task  either  has  a  queued  task  or  is  executing  a  rendez¬ 
vous.  (This  is  the  normal  form  of  Ada  blocking  and  is  the  price  paid  for  consistency 
in  shared  data.) 

•  Push-through  blocking:  a  medium-priority  task  is  unable  to  execute  because  a  sen/er 
task  executing  on  behalf  of  a  lower  priority  task  is  blocking  the  execution  of  a  high- 
priority  task  and,  therefore,  is  executing  instead  of  the  medium-priority  task.  (This  is 
the  price  paid  to  avoid  indefinite  blocking  of  high-priority  tasks.) 

•  Ceiling  blocking:  although  the  called  task  would  normally  be  able  to  accept  the  call 
(because  it  is  not  executing  on  behalf  of  any  other  task),  some  server  task  is  execut¬ 
ing  with  a  priority  ceiling  higher  than  or  equal  to  that  of  the  calling  task.  (This  is  the 
price  paid  to  avoid  deadlock  and  chained  blocking.  Although  it  sometimes  introduces 
extra  delays  in  sen/idng  a  call,  the  overall  effect  is  to  reduce  the  worst-case  blocking 
delays  for  high-priorKy  tasks.) 

An  example  showing  the  effect  of  the  priority  ceiling  protocol  is  given  in  Figure  1 .  This  figure 
shows  the  execution  of  seven  tasks,  including  two  sen/er  tasks.  The  non-sen/er  tasks  are  labeled 
with  their  priority,  e.g.,  task  5  has  the  highest  priority.  The  sen/er  tasks  have  the  lowest  priority; 
SI  has  priority  0  and  S2  has  priority  -1 .  The  calling  relationships  among  the  tasks  are  as  follows; 

•  Task  5  calls  an  entry  of  sen/er  task  S2.  The  entry  call  takes  one  unit  of  time. 

•  Task  4  calls  an  entry  of  server  task  Si .  The  entry  call  takes  one  unit  of  time. 

•  Task  3  makes  no  entry  calls. 

•  Task  2  calls  an  entry  of  sen/er  task  S2;  during  this  rendezvous,  S2  calls  an  entry  of 
task  SI .  (This  iHustrates  the  effect  of  the  protocol  for  nested  entry  calls.)  The  entry 
call  takes  4  units  of  time,  including  the  time  used  by  the  rendezvous  with  SI . 

•  Task  1  calls  an  entry  of  server  task  Si .  The  entry  executes  using  4  unKs  of  time. 

Since  Si  is  called  on  behalf  of  tasks  1,  2,  and  4,  Si’s  priority  ceiling  is  4.  Since  S2  is  called  on 
behalf  of  tasks  2  and  5,  its  priority  ceiling  is  5. 

The  actions  illustrated  by  Figure  1  are  explained  below,  but  the  overall  effect  to  note  is  that  the 
higher  priority  tasks  complete  their  execution  much  earlier  under  the  priority  ceiling  protocol  than 
under  the  basic  priority  inheritance  protocol  (illustrated  in  Figure  2). 

•  At  time  t),  all  tasks  are  activated,  but  only  tasks  1,  Si,  and  S2  are  ready  to  run. 

Since  task  1  has  the  highest  priority,  its  execution  begins. 
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called  by 

S2  Ip 

•MMi4^XX^ 


XX\XXXXX\,XX\XX\XXXV^^N^^VXX\XXX\XXXX^^™|i|rfxXXX\XXXXXXVXXXXX^XXXX‘ 


p  PIP  pip  pip  p 
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P  :P  P 


►XXXXXXXX5kXXXXXXXX^XXNXXVXX\WXXXXXXXX|i*»>NxXX^XXXXXXXXjwXXXxVVXX>BBoJlI>OCC 


xxxs^xxxxxvxxl 


p  Pl2*2gci 


^3  ^  ^7 


^9  ^1  ^3  *15  *17  *19  *21 


^v.vJ  server  called  by  task  1 ,  executing  in  rendezvous  at  priority  4.  The  thin  line  indicates  the  end 
ol  the  rendezvous  with  task  1 . 

server  executing  at  priority  1 ;  black  part  indicates  code  outside  of  rendezvous;  the  shaded 
part  indicates  code  inside  the  rendezvous. 


Cl  I  accepted  call  to  server  1 


D1 1  directly  blocked  call  to  server  1 


P  preempted  by  higher  priority  task  execution 


executing  code  outside  rendezvous 


Bp  I  push-through  blocking 


B2 1  ceilirrg  blocking  (call  to  server  2) 


Figure  1 :  The  Priority  Ceiling  Protocol 
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•  At  time  t2.  task  1  attempts  to  call  server  Si.  Since  rx)  server  tasks  are  executing  on 
behalf  of  any  task,  the  call  succeeds.  Since  the  server  has  not  yet  had  time  to 
execute  its  select  statement,  the  call  is  queued,  and  server  SI  starts  executing  at 
priority  1,  the  priority  of  its  queued  task.  Eventually  its  select  statement  is  executed 
and  the  waiting  call  is  accepted;  the  rendezvous  starts.  Execution  continues  at  prior¬ 
ity  1. 

•  At  time  tg,  task  2  starts  its  execution.  Since  task  2  has  higher  priority  than  the 
current  priority  of  server  tasks  Si.  S2,  and  task  1.  the  execution  of  these  tasks  is 
preempted. 

•  At  time  t4.  task  2  attempts  to  call  server  task  S2.  We  now  examine  the  priority 
ceilings  of  alt  server  tasks  that  are  executing  on  behalf  of  some  task  other  than  task 
2.  There  is  only  one  (server  task  Si)  and  its  priority  ceiling  is  4.  Since  this  priority 
ceiling  exceeds  task  2's  current  priority,  task  2  is  blocked;  i.e.,  its  execution  is 
suspended  and  the  entry  call  is  not  made.  In  particular,  task  2  is  no/  queued  for  S2. 
Since  SI  blocks  the  execution  of  task  2,  Si  inherits  task  2's  priority.  SI  is  now  the 
highest  priority  task  that  can  run. 

The  blocking  of  the  call  to  S2  is  an  example  of  ceiling  blocking.  This  kind  of  blocking 
occurs  because  of  the  priority  ceiling  protocol.  Although  it  may  seem  counter¬ 
intuitive  to  block  task  2  even  though  its  call  can  othenvise  be  accei^ed,  the  example 
given  here  shows  that  the  overall  effect  on  timing  behavior  is  beneficial. 

•  At  time  t5,  task  3  starts  its  execution.  Since  its  priority  is  higher  than  the  current 
priority  of  any  task  that  is  ready  to  run,  it  preempts  the  execution  of  tasks  S2,  St ,  t , 
and  2. 

•  At  time  tg,  task  4  starts  its  execution.  Since  its  pn'or'ity  is  higher  than  the  execution 
priority  of  any  other  task  that  is  ready  to  run,  it  preempts  the  executton  of  tasks  S2, 
SI,  1,2,  and  3. 

•  At  time  ty,  task  4  attempts  to  call  server  task  Si.  We  examine  the  prtority  ceiling  of 
all  server  tasks  that  are  executing  on  behalf  of  some  task  other  than  task  4.  S1  is 
the  only  such  task  (it  is  executing  on  behalf  of  task  1).  Si’s  priority  ceiling  is  4,  which 
is  equal  to  the  priority  of  the  calling  task,  so  task  4’s  execution  is  blocked.  In  this 
case,  since  task  4  is  calling  Si  and  SI  is  already  in  rendezvous  with  another  task, 
the  call  could  not  be  accepted  in  any  case.  This  is,  therefore,  an  example  of  direct 
blocking. 

Since  SI  is  blocking  task  4,  its  execution  priority  is  increased  to  4.  Si  is  now  the 
highest  priority  task  able  to  execute.  Tasks  2  and  3  are  now  blocked  from  execution 
because  Si  is  executing  wfth  a  higher  priority.  Since  SI  is  executing  on  behalf  of 
task  1 ,  its  execution  priority  would  normally  be  1 .  If  it  did  not  inherit  the  priority  of  the 
task  it  is  blocking,  task  4  would  still  be  blocked,  but  task  3  would  be  the  highest 
priority  task  able  to  run  and  would  preempt  the  execution  of  tasks  2, 1,  Si,  and  S2. 
The  effect  would  be  to  delay  task  4  even  longer.  The  blocking  of  tasks  2  and  3  is  an 
example  of  push-through  blocking. 

•  At  time  tg,  task  5  starts  its  execution.  Since  its  priority  is  higher  than  the  current 
priority  of  any  executing  task,  SVs  execution  is  preempted,  and  task  5  starts  to 
execute. 

•  At  time  tg,  task  5  attempts  to  call  S2.  We  examine  the  priority  ceiling  of  all  server 
tasks  that  are  executing  on  behalf  of  some  task  other  than  task  5.  SI  is  the  only 
such  task  (executing  on  behalf  of  task  1).  Si’s  priority  ceiling  is  4.  which  is  less  than 
task  S’s  priority,  so  the  call  can  be  accepted.  Since  S2  has  not  yet  had  an  oppor¬ 
tunity  to  execute  its  select  statement,  task  5  is  queued.  S2  is  given  the  priority  of  its 
queued  task  and  Ks  execution  starts.  When  its  select  statement  is  executed,  the 
waiting  call  is  accepted,  and  the  rendezvous  starts;  execution  continues  at  priority  5. 
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Task  5‘s  call  to  S2  can  be  accepted  because  task  2's  attempted  call  (at  time  14)  was 
blocked.  This  is  where  the  blocking  of  task  2  pays  off— a  high-priority  task  that  would 
otherwise  be  blocked  while  S2  is  executing  can  now  be  serviced.  Comparison  with 
the  basic  priority  inheritance  protocol  (Figure  2)  is  worthwhile. 

•  At  time  t^g,  the  rendezvous  with  S2  is  completed.  S2  reverts  to  its  assigned  priority, 
so  its  execution  is  preempted  by  the  execution  of  task  5. 

•  At  time  t^^,  task  5  completes  its  execution.  Task  4's  call  to  St  is  still  blocked  since 
St  has  not  yet  finished  its  rendezvous.  St  has  priority  4  and  therefore  continues  its 
execution. 

•  At  time  t^2>  S'*  completes  its  rendezvous.  Its  priority  returns  to  normal.  St  has 

been  blocking  the  execution  of  tasks  2,  3,  and  4.  Completion  of  the  rendezvous 
means  tasks  2  and  4  are  no  longer  blocked  because  St  is  no  longer  executing  on 
behalf  of  any  task.  In  addition,  St 's  low-priority  means  it  no  longer  blocks  task  3.  So 
all  tasks  are  eligible  to  run.  Since  task  4  has  the  highest  priority,  its  execution 
resumes. 

Task  4  was  suspended  just  before  making  the  call  to  St .  Now  that  its  execution  has 
resumed,  it  again  attempts  to  call  St.  Since  there  are  no  server  tasks  executing  on 
behalf  of  any  task,  the  call  succeeds.  Since  St  just  completed  its  rendezvous,  it  is 
not  yet  ready  to  accept  the  call  (it  is  not  yet  waiting  at  an  accept  statement),  so  the 
call  is  queued.  Since  the  call  is  queued,  St’s  current  priority  is  raised  to  the  current 
priority  of  the  calling  task. 

51  now  has  the  highest  execution  priority.  It  begins  execution  and  eventually  ex¬ 
ecutes  its  select  statement.  The  waiting  call  is  accepted  and  the  rendezvous  begins. 
Execution  continues  at  priority  4. 

Note  that  if  task  4  had  attempted  to  call  S2  instead  of  S1 ,  its  call  would  have  been 
serviced  before  task  2's  call,  even  though  task  2  made  its  call  first.  In  effect,  calls 
are  automaticalty  serviced  in  order  of  priority  under  the  priority  ceiling  (and  the  basic 
priority  inheritance)  protocol. 

•  At  time  t^3,  task  S1  completes  its  rendezvous.  Its  priority  returns  to  normal.  All  tasks 
are  now  eligible  to  run.  Since  task  4  has  completed  its  call  to  S1  and  has  the  highest 
priority,  its  execution  resumes. 

•  At  time  t^4,  task  4  completes  its  execution.  Task  3  now  has  the  highest  priority  and 
resumes  its  execution. 

•  At  time  t^5,  task  3  completes  its  execution.  Task  2  now  has  the  highest  priority  and 
resumes  its  execution  by  attempting  to  call  server  S2.  Since  no  server  tasks  are 
executing  on  behalf  of  any  tasks,  the  call  succeeds.  Since  S2  has  just  completed  a 
rendezvous,  it  is  not  yet  ready  to  accept  the  call,  so  the  call  is  queued.  Since  the  call 
is  queued,  S2‘s  execution  priority  is  raised  to  the  execution  priority  of  the  calling  task. 

52  now  has  the  highest  execution  priority.  It  begins  execution  and  eventually  ex¬ 
ecutes  its  select  statement.  The  waiting  call  is  accepted  and  the  rendezvous  begins. 
Execution  continues  at  priority  2,  the  current  priority  of  the  calling  task. 

•  At  time  t^g,  execution  of  the  rendezvous  continues. 

•  At  time  t^7,  S2  attempts  to  call  S1 .  S2  is  executing  on  behalf  of  task  2.  We  check  to 
see  if  there  are  any  other  server  tasks  that  are  executing  on  behalf  of  some  task 
other  than  task  2.  Since  there  are  no  such  tasks,  it  doesnl  matter  that  S2’s  current 
priority  is  less  than  Si 's  priority  ceiling;  the  call  succeeds. 

The  call  is  queued,  and  Si  starts  executing  at  priority  2,  the  current  priority  of  its 
caller,  S2.  Eventually  the  call  is  accepted  and  the  rendezvous  begins. 
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If  during  this  execution  of  S1 ,  task  5  started  execution  and  attempted  to  cali  S2,  then 
S2  and  S1  would  block  the  execution  of  task  5,  and  S1  would  therefore  resume 
execution  at  priority  5.  Note  that  priority  5  is  higher  than  St's  priority  ceiling.  The 
priority  ceiling  is  only  determined  by  the  priority  of  tasks  that  call  a  server  directly  or 
indirectly;  it  is  not  affected  by  the  priority  of  tasks  that  a  server  can  block.  Therefore, 
a  server's  priority  ceiling  is  not  its  maximum  execution  priority  but,  instead,  reflects 
the  maximum  priority  of  Hs  client  tasks. 

•  At  time  tf 3,  S1  completes  execution  of  the  rendezvous.  Si 's  priority  returns  to  nor¬ 
mal  and  its  execution  is  preempted  by  S2,  which  is  still  executing  at  priority  2.  S2 
continues  executing  tts  rendezvous,  at  the  priority  of  its  calling  task. 

•  At  tinr>e  t^g,  S2  completes  execution  of  its  rendezvous.  Its  priority  returns  to  normal, 
so  its  execution  is  preempted  by  task  2. 

•  At  time  tgot  task  2  completes  its  execution.  Task  1  can  now  resume  its  execution. 

•  At  time  tgv  task  1  completes  its  execution. 

We  now  determine  the  worst-case  blocking  time  for  each  task.  Under  the  priority  ceiling  protocol, 
a  server  S  can  block  a  non-server  task  J: 

•  if  the  priority  ceiling  of  S  is  higher  than  or  equal  to  the  priority  of  J,  and 

•  if  there  exists  a  lower  priority  task  which  may  call  S. 

In  this  example,  the  maximal  entry  call  duration  of  both  S,  and  is  4.  Hence,  if  a  task  can  be 
blocked  once  by  either  or  Sg,  the  blocking  time  is  4.  Finally,  recall  that  the  priority  ceilings  of 
and  Sg  are  4  and  5,  respectively.  The  worst-case  blocking  time  for  each  task  is  as  follows. 

•  The  worst-case  blocking  time  for  task  1,  is  zero  since  there  are  no  lower  priority 
client  tasks  that  can  invoke  a  server. 

•  The  worst-case  blocking  time  for  task  2,  B2.  is  4  because  task  2's  priority  is  lower 
than  the  ceiling  of  server  S,.  In  addition,  can  be  called  by  lower  priority  task  1. 

Task  2's  priority  is  also  lower  than  the  priority  ceiling  of  Sg,  but  since  no  lower  priority 
client  task  calls  S2,  task  2's  blocking  time  is  independent  of  the  time  taken  for  any 
entry  calls  to  82- 

•  The  worst-case  blocking  time  for  task  3,  B3,  is  4  because  task  3’s  priority  is  lower 
than  the  priority  ceilings  of  and  82-  In  addition,  either  server  can  be  called  by  a 
lower  priority  task,  and  the  maximum  duratton  of  each  such  call  is  4.  Note  that  task  3 
has  a  non-zero  blocking  time  even  though  it  makes  no  entry  calls. 

•  The  worst-case  blocking  time  for  task  4,  B4,  is  4  because  task  4's  priority  is  not 
higher  than  the  ceilings  of  servers  8^  and  82-  Both  servers  can  be  called  by  lower 
priority  tasks,  and  the  maximum  duration  of  each  such  call  is  4. 

•  The  worst-case  blocking  time  for  task  5,  B^,  is  4  because  server  82's  priority  ceiling 
is  equal  to  the  priority  of  task  5,  82  can  be  called  by  task  2,  and  task  2's  entry  call 
takes  4  units  of  time. 

Note  that  to  minimize  the  effect  of  the  blocking  times,  entry  calls  of  low-priority  tasks  should  be 
short. 

The  effect  of  the  basic  priority  inheritance  protocol  is  indicated  in  Figure  2. 

•  At  time  t^,  81  and  82  are  preempted  and  task  I's  execution  begins. 
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server  called  by  task  1,  executing  in  rendezvous  at  priority  4.  The  thin  line  indicates  the  end 
ol  the  rendezvous  wHh  task  1 . 


server  executing  at  priority  1;  black  part  indicates  code  outside  of  rendezvous;  the  shaded 
part  indicates  code  inside  the  rendezvous. 

accepted  call  to  server  1  P  preempted  by  higher  priority  task  execution 


directly  blocked  call  to  server  1 


H  executing  code  outside  rendezvous 


push-through  blocking 


Figure  2:  The  Basic  Inheritance  Protocol 
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Figure  2:  The  Basic  inheritance  Protocol 
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•  At  time  t2.  task  1  attempts  to  call  server  S1 .  Since  SI  is  not  executing  on  behalf  of 
any  task,  the  call  succeeds:  since  Si  has  not  yet  had  time  to  execute  its  select 
statement,  the  call  is  queued;  server  Si  starts  executing  at  priority  1 ,  the  priority  of 
its  queued  task.  Eventually  its  select  statement  is  executed  and  the  waiting  call  is 
accepted;  the  rendezvous  starts.  Execution  continues  at  priority  1 . 

•  At  time  tg,  task  2  starts  its  execution.  Since  task  2  has  higher  priority  than  the 
current  priority  of  tasks  Si,  S2,  and  task  1,  the  execution  of  these  tasks  is 
preempted. 

•  At  time  t4,  task  2  attempts  to  call  server  task  S2.  Since  S2  is  not  executing  on  behalf 
of  any  task,  the  call  is  accepted  (unlike  the  case  of  the  priority  ceiling  protocol). 
Since  S2  has  not  yet  had  time  to  execute  its  select  statement,  the  call  is  queued; 
server  S2  starts  executing  at  priority  2,  the  priority  of  its  queued  task.  Eventually  its 
select  statement  is  executed  and  the  waiting  call  is  accepted;  the  rendezvous  starts. 
Execution  continues  at  priority  2. 

•  At  time  tg,  task  3  starts  its  execution.  Since  its  priority  is  higher  than  the  current 
priority  of  any  task  that  is  ready  to  run,  it  preempts  the  execution  of  tasks  S2,  S1 , 1 , 
and  2. 

•  At  time  tg,  task  4  starts  its  execution.  Since  its  prtority  is  higher  than  the  execution 
priority  of  any  other  task  that  is  ready  to  run,  it  preempts  the  execution  of  tasks  S2, 
SI,  1, 2,  and  3. 

•  At  time  t7,  task  4  attempts  to  call  senrer  task  Si .  Since  SI  is  executing  on  behalf  of 
task  1,  task  4  is  blocked;  i.e.,  its  execution  is  suspended  and  the  entry  call  is  not 
made.  Since  Si  now  blocks  the  execution  of  task  4,  S1  inherits  task  4's  priority  and 
resumes  execution. 

•  At  time  tg,  task  5  starts  its  execution.  Since  its  priority  is  higher  than  the  current 
priority  of  any  executing  task.  Si ’s  execution  is  preempted  and  task  5  starts  to  ex¬ 
ecute. 

•  At  time  tg,  task  5  attempts  to  call  S2.  S2  is  executing  on  behalf  of  task  2,  so  task  5  is 
blocked.  Since  S2  now  blocks  the  execution  of  task  5,  it  inherits  task  5’s  priority  and 
is  now  the  highest  priority  task  ready  to  run.  Note  that  under  the  priority  ceiling 
protocol,  task  2's  earlier  call  to  S2  had  been  blocked  so  that  task  5's  call  could  be 
accepted. 

•  At  time  t^o<  attempts  to  call  SI .  Since  SI  is  executing  on  behalf  of  task  1 ,  this  call 
is  blocked  and  Si  inherits  the  current  priority  of  S2.  Si  is  now  the  highest  priority 
task  ready  to  run;  it  resumes  execution  at  priority  5. 

The  situation  at  t^Q  illustrates  how  chained  blocking  can  arise  under  the  basic  priority 
inheritance  protocol.  Task  5's  call  cannot  be  accepted  by  S2  until  both  S2  and  S1 
complete  their  execution  on  behalf  of  tasks  1  and  2.  Under  the  priority  ceiling 
protocol,  server  calls  on  behalf  of  at  most  one  task  need  to  be  completed.  Under  the 
inheritance  protocoi,  chained  blocking  can  occur  even  when  nested  server  calls  are 
not  made. 

•  At  time  t^^,  execution  of  SI  continues  at  priority  5. 

•  At  time  t,2.  SI  completes  its  rendezvous.  Its  priority  returns  to  normal.  Sl  has  been 
blocking  tasks  4  and  5.  Since  S2  is  still  blocking  task  5,  it  executes  at  priority  5.  Its 
execution  is  resumed  and  its  call  to  Si  is  now  accepted.  Note  that  S2's  call  suc¬ 
ceeds  even  though  task  4  called  Si  first— the  effect  of  the  blocking  mle  is  to  ensure 
calls  are  accepted  in  order  of  priority  rather  than  in  order  of  time. 

•  At  time  t^g,  task  SI  completes  its  rendezvous.  Its  priority  returns  to  normal.  All  tasks 
are  now  eligible  to  run.  Since  S2  is  still  blocking  task  5,  its  execution  resumes  at 
priority  5. 
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•  At  time  t^4,  S2  completes  its  rendezvous.  Its  piiority  returns  to  normal  and  no  longer 
blocks  task  5.  Task  5  is  now  the  highest  priority  ready  to  run,  and  its  call  to  S2 
succeeds.  S2  resumes  execution  at  priority  5. 

•  At  time  t^5,  S2  completes  task  5‘s  call.  Its  priority  returns  to  normal.  Task  5  con¬ 
tinues  its  execution. 

•  At  time  t^g,  task  5  completes  its  execution.  Task  4  is  rx>w  the  highest  priority  task 
ready  to  execute.  Its  call  to  S1  succeeds,  and  Si  starts  executing  at  priority  4. 

•  At  time  t^7,  SI  completes  task  4’s  call,  its  priority  returns  to  normal,  and  task  4 
continues  its  execution. 

•  At  times  t^g.2v  tasks  4, 3, 2,  and  1  complete  their  execution. 
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